Add AI Tools plugin detection to the user-agent#5924
Conversation
Integration test reportCommit: 20147d1
8 interesting tests: 4 SKIP, 2 RECOVERED, 2 flaky
Top 10 slowest tests (at least 2 minutes):
|
f0bf565 to
20e717d
Compare
20e717d to
7cb15f0
Compare
7cb15f0 to
72cf29c
Compare
72cf29c to
20147d1
Compare
| func withAiToolsInUserAgent(ctx context.Context) context.Context { | ||
| // Each tool appends one aitools/<tool>_<version> pair to the same context; | ||
| // these accumulate, so this is not the accidental context nesting fatcontext | ||
| // flags. | ||
| for _, tool := range installer.InstalledTools(ctx) { | ||
| ctx = useragent.InContext(ctx, aiToolsKey, tool) //nolint:fatcontext | ||
| } | ||
| return ctx | ||
| } |
There was a problem hiding this comment.
Could we also test this function as this the single top level call point for new functionality? Maybe move it in installer as a public function?
There was a problem hiding this comment.
I am not sure which tests you want to add.
There was a problem hiding this comment.
Maybe move it in installer as a public function?
I am fine with doing the change. As per Claude, it is just consistent with other parts of the code.
There was a problem hiding this comment.
I am not sure which tests you want to add.
Testing that the returned context is correct given the passed input and the environment. Think about it as an end-to-end unit test for your new call tree.
I am fine with doing the change. As per Claude, it is just consistent with other parts of the code
Testing this function would require to share some of the testing utilities you have in the other package. Collocating them centralizes that logic.
20147d1 to
2780658
Compare
2780658 to
7afc61b
Compare
05c3367 to
b38dfa2
Compare
|
Force merging to unblock PR - given that CI is red. |
🥞 Stacked PR
Use this link to review incremental changes.
Changes
Emit an
aitools/<tool>pair in the CLI user-agent for each coding tool that has the Databricks plugin installed (e.g.aitools/claude-code aitools/codex), so plugin adoption is measurable per tool from request telemetry. When no tool has it installed, noaitools/pair is added at all. A tool counts as installed if either signal says so: the plugin is present in the tool's own plugin cache (<configDir>/plugins/cache/*/databricks), or the plugin is recorded in the CLI install state. Detection runs over every agent in the registry that ships a plugin (Claude Code, Codex, Copilot); skills-only agents are not reported.Why
Coding-agent usage is already visible in the user-agent (the SDK's
agent/dimension), but whether Databricks AI Tools are actually installed is not, so adoption cannot be measured. Reading only the CLI install state would undercount badly: the Databricks plugin is published in the agents' own plugin marketplaces, so an install done directly through the agent (not viadatabricks aitools install) leaves nothing in the CLI state. The plugin cache on disk is the ground truth that captures those direct installs. Taking the union of the on-disk cache and the CLI state maximizes coverage and only ever over-counts a stale record, never hides a real install — the right bias for an adoption signal.Tests
Unit tests for on-disk plugin detection (
HasDatabricksPlugin, including the varying marketplace segment and wrong-plugin-id cases) and forInstalledToolscovering disk-only (direct-marketplace install), state-only across global and project scope, the disk+state union with dedup, and skipping records for agents no longer in the registry. Acmd/roottest asserts the user-agent emission contract (oneaitools/<tool>pair per installed tool, nothing when none). The existing user-agent acceptance test is unaffected: the test harness runs with an isolated empty home directory, so the dimension stays silent.